The present invention relates to a process for controlling the use of software developed under a specified platform, associated with a device provided with an electronic circuit with read/write retentive memory, connected to the terminals of a parallel port between a computer and a peripheral apparatus, in which signals are processed in the device and/or are returned from said device to the computer in response to signals transmitted from this computer.
The term platform is understood to mean an environment corresponding to a specified operating system, such as the Windows(trademark) environment, the Unix(trademark) environment or other environments (Apple(trademark), for example), which call in particular upon dynamic link libraries (DLL, the initials of Dynamic Lien Librairy
It is known that dynamic link libraries (DLLs) constitute an important utility within operating systems. DLLs offer the possibility of connecting prewritten modules into the operating system. This makes it possible for the applications to share the common coding, to modularize the regularly used functions and to provide a degree of expandability.
The present invention also relates to a system for the interactive control of the use of software items.
It finds a particularly important although nonexclusive application in the field of protection against the copying of software items which is used on microcomputers under a 16-bit and 32-bit Windows(trademark) platform.
Methods are already known for protecting software items stored, for example, on diskettes making it possible to preclude the copying of these diskettes.
The first method of protection consists in short-circuiting the microcomputer program portion which reads the diskettes.
A second method consists in marking the diskette in an irreversible manner by destroying a particular site on the magnetic medium with a laser ray.
The two methods mentioned above have drawbacks in particular because they prevent the user from making a backup copy of his programs.
A third method consists in marking the computer by means of an electronic device, sometimes called a key.
The program, while it is executing, will then verify the presence of this key consisting of an electronic circuit which returns codes when it is requested.
This circuit can be housed directly in one of the computer""s expansion connectors, or more simply be plugged into one of the external sockets or ports, for example that of the printer, without thereby disturbing the operation of the latter.
It is thus possible to copy the software at will. This system which has been further improved by making the keys directly programmable by virtue of a read/write retentive memory is by far the most effective.
However, it has a number of drawbacks.
Thus, in software items which currently operate on a specified platform, and more particularly those which operate on a Windows(trademark) platform (16 and 32 bits), problems arise regarding the compatibility of the systems used during the programming by the programmer of the key as a function of the languages and/or generations of software which it uses.
The present invention aims to provide a process and a system for controlling the operating of software which is better than those previously known at meeting the requirements of practice, in particular in that it makes it possible to avoid the drawbacks mentioned above, and in that it makes it possible, through simplified installation procedures, henceforth to be unconcerned with the end platform on which the application will operate.
With said invention, the programmer will therefore authorize or otherwise the operation of the software protected in an optimized manner, this being a particularly advantageous technical result in an era in which the pirating of software is unfortunately on the increase.
To this end, the invention proposes in particular a process for controlling the use of software developed under a specified platform, associated with a device provided with an electronic circuit with read/write retentive memory, connected to the terminals of a parallel port between a computer and a peripheral apparatus, in which signals are processed in the device and/or are returned from said device to the computer in response to signals transmitted from this computer, characterized in that
the circuit of the device is written to or read from by calling upon a function built into an object file (.OBJ) or a Dynamic Library file (.DLL) previously inserted into said software, said function having the following form:
result=cnrm(var1, var2, . . . varn) with n greater than 3
in which var1 to varn correspond to particular values depending on what it is desired to execute with the device and to at least one specific value corresponding to a specified user,
said function being devised so as automatically to detect the type of specified platform, and calculate the software execution context as a function of said platform.
After the call, var1 to varn contain result values dependent on the action executed and hence on the values given during the call. Result will contain the value of var1 after the call.
More precisely the software interface which makes it possible to read from and write to the key takes the following forms:
an object file (.OBJ) to be used for the programs written in compiled languages such as C or pascal, for which calling complies with what is described above, or
a dynamic library (.DLL) to be used by the programs written in interpreted or semicompiled languages (VISUAL BASIC, WINDEV), but also in certain cases with compiled languages.
Advantageously, during the implementation of the linking function (Login) between the software and the device, the key and/or its position are identified by way of a specific value (cfgFun or cfgKey), for example given by the software, or obtained while exploring the successive keys, and this specific value is stored in memory and used later as a constant when operating said software.
In an advantageous embodiment the function cnrm is devised (function cnrmcb) so as to recall the software at least once while operating, so as to verify that it is indeed the original function cnrm which has been called.
The term original function cnrm is understood to mean the function which has been designed and provided to operate originally with the device, by the constructor of the device.
In an advantageous embodiment, the specified platform is a Windows(trademark) platform, said function cnrm being devised so as to allow automatic recognition of the type of passing of parameters by reference or by value implemented within the software.
Let us recall that in this case, by virtue of the nature of certain programming languages, the dynamic library is in reality constructed in the form of two dynamic libraries:
a dynamic library with passing of parameters by reference, for which calling complies with what is described above, that is to say for which Result contains the value var1 after the call (i.e. a first DLL file for 16-bit application and a second DLL file for 32-bit application),
a dynamic library with passing of parameters by value for which an additional parameter makes it possible to define which value from var1 to varn is to be placed in Result after the call. (i.e. a third DLL file for 16-bit applications and a fourth DLL file for 32-bit applications).
Prior to the invention, additional mechanisms were necessary during operation under the WINDOWS NT operating system for a 16-bit application (written for WINDOWS 3.xx).
The programmer was in effect obliged to use a dynamic library even for a compiled language, this being so that the first DLL file can be replaced by a fifth DLL file specific to the WINDOWS NT environment.
This fifth specific DLL file then itself called a sixth 32-bit DLL file specific to WINDOWS NT which in turn called the peripheral/central processing unit interface module (or driver) responsible for the inputs/outputs to the key.
The same type of mechanism had to be used for the third DLL file in the case of the passing of parameters by reference.
To summarize, the following cases in point existed under the Windows(trademark) platform before the invention:
With a 16-bit application with compiled programs when using the .OBJ library, operations were performed exclusively under 16-bit WINDOWS.
When using the first DLL file (16-bit WINDOWS version) it was however necessary to replace this first DLL file by a special NT version to provide a sixth special DLL file for WINDOWS NT and to install the NT driver.
With a 16-bit application with semicompiled or interpreted programs, if the application allows the passing of parameters by references, when using the first DLL file (16-bit WINDOWS version) to operate under WINDOWS NT it was necessary to replace this first DLL file by a special NT version, to provide a fifth special file for WINDOWS NT and to install the NT driver.
However, if the application did not allow the passing of parameters by references when using the third DLL file (16-bit WINDOWS version) to operate under WINDOWS NT it was necessary to replace this third DLL file by a special NT version, to provide another special DLL for WINDOWS NT and to install the NT driver.
With a 32-bit application with compiled programs, when using the .OBJ library, operations were on the other hand performed exclusively under 32-bit WINDOWS (WINDOWS 95 or WIN32S). Operations were not carried out under NT, in which case a specific .OBJ is necessary and hence two different programs are necessary for the 32 bits.
When using the second DLL file (32-bit WINDOWS version) to operate under WINDOWS NT it was, on the other hand, necessary to replace the second DLL file by a special NT version and to install the NT driver.
Finally, with a 32-bit application with semicompiled or interpreted programs, if the application allowed the passing of parameters by references, when using the second DLL file (32-bit WINDOWS version) to operate under WINDOWS NT it was necessary here again to replace the second DLL file by a special NT version and to install the NT driver.
On the other hand, if the application did not allow the passing of parameters by references, when using the fourth DLL file (32-bit WINDOWS version) to operate under WINDOWS NT it was necessary to replace this fourth DLL file by a special NT version and obligatory to install the NT driver.
Such processes therefore have drawbacks.
Indeed the number of DLLs and the differentiation between DLLs depending on the execution platform oblige the users to consider all the cases in point and to have a complex installation procedure.
The compiled programs are compelled to use obligatorily a DLL so that they can be ported to NT without compilation.
An understanding of the various possible cases is therefore not obvious and led programmers to make errors, and this increased the costs of intervention when installing and using softwares and thereby gave rise to unsatisfactory technical effects.
Since the specified platform is a Windows platform, and/or said function cnrm is devised so as to allow automatic recognition of the type of passing of parameters by reference or by value implemented within the software, these various drawbacks are alleviated.
Conventionally, before any key manipulation, it is known that an operation referred to hereafter as Login is performed.
Login is in effect an action which is necessary in order to be certain of reading from and writing to the correct key.
According to one embodiment of the invention, with each call of cnrm, the editor codes will thus, for example, be passed in the variables var2, var3 so as to validate the correct key.
During key login, a memory area (stack) associated with login is then allocated and will store the return values of var1 to varn and also the elements of the platform-specific execution context.
To allow the recognition and automatic passing of parameters by reference and by value, the call to the cnrm function is supplemented with a function cnrmvar whose objective is to retrieve the post-call contents of var1 to varn.
Its form is as follows:
Result=cnrmvar(login handle, index of the variable (1 to n)).
It will be used instead of the corresponding variable.
For example, in an advantageous embodiment of the invention where the value n is equal to 8, instead of using a method of the type:
var1=12; {register read}
var2=code0; {editor cord}
var3=code1; {editor code}
var4=key 0; {editor password}
var5=0;
var6=0;
var7=5; {index of the register to be read}
var8=0;
res=cnrm (var1, var2, var3, var4, var5, var6,
var7, var8);
if (var1==True {
. . .
}
An assignment is provided as follows:
var1=12; {register read)
var2=code0; {editor code}
var3=code1; {editor code}
var4=key 0; {editor password}
var5=0;
var6=0;
var7=5; {index of the register to be read}
var8=0;
res=cnrm (var1, var2, var3, var4, var5, var6,
var7, var8);
if (cnrmvar(cfgLog, 1)==True {
. . .
}
At the time of the call, the function cnrm will analyze the contents of the stack. If it finds the editor codes in the stack then it will know that this is a passing by value, otherwise this is a passing by reference.
It should be noted that this mechanism requires that the software interfaces be customized based on editor, that each editor-based interface be capable of recognizing the editor codes in the stack, and that each editor possess different codes, this being provided for and implemented by the manufacturer of the keys.
In this way the programmer need no longer concern himself with the mode of parameter passing, and can choose the mode which he desires when he desires. When using semicompiled programs implementing parameter passing by value only, it will have a mode of operation and a principal of writing which is identical to that for a program compiled with parameter passing by reference.
The call to the function cnrm is made uniform and the calls can be made in the same way, irrespective of the language.
In an advantageous embodiment the execution context is set up once only, during the first implementation of the function linking the software and the device (input login).
This thereby affords the maximum performance in respect of the other calls to the function cnrm.
Advantageously the process additionally comprises the implementation of a method of protection in which a few sensitive functions of the software to be protected are chosen, the entry point of these functions is masked by an indirect call, and the structure which contains the entry point of said functions is encrypted.
Thus, it is certain that the key has indeed been read, otherwise decryption is not carried out, the entry points of the functions not being found.
Stated otherwise, if a normal user having a license does not put in his key, he will obtain the xe2x80x9ckey absentxe2x80x9d message.
If a pirate tries to replace the key or to delete the test for the presence of the key, decryption is not carried out, and in this case the entry points of the functions are not found.
The encryption is advantageously carried out by an external program after compilation and link editing. It can for example use a so-called TAG1 string which must be unique in order to find the area to be encrypted and the length of said area. More generally, the encryption tool will be adapted by the programmer as a function of his specific requirements.
The invention also relates to a system implementing the process described above.
It likewise relates to a system for controlling the use of software developed under a specified platform, comprising a device provided with an electronic circuit with read/write retentive memory, connectable to the terminals of a parallel port between a computer and a peripheral apparatus, devised so as to process and/or return signals to the computer in response to signals transmitted from the latter, characterized in that
the system comprises means for writing to and reading from the circuit of the device by calling upon a function built into an object file (.OBJ) or a Dynamic Library file (.DLL) previously inserted into said software, said function having the following form:
result=cnmr(var1, var2, . . . var8)
in which var1 to var8 correspond to particular values depending on what it is desired to execute with the device and to at least one specific value corresponding to a specified user,
said function being devised so as automatically to detect the type of specified platform, and calculate the software execution context as a function of said platform.
Advantageously the system moreover comprises means for automatically recognizing the type of passing of parameters by reference or by value implemented within the software.
The invention will be better understood on reading the description of embodiments given below by way of non-limiting example, by making reference in particular to various tables.